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METHOD AND APPARATUS FOR CONVERTING PROGRAMS AND SOURCE 
CODE FILES WRITTEN IN A PROGRAMMING LANGUAGE TO EQUIVALENT 

MARKUP LANGUAGE FILES 

5 

CROSS-REFERENCE TO RELATED APPLICATIONS 

The present application is related to Application 
Serial Number (Attorney Docket Number AT9-98-921) , filed 
10 (concurrently herewith), entitled "Method and Apparatus 
for Converting Application Programming Interfaces Into 
Equivalent Markup Language Elements," hereby incorporated 
by reference, 

15 BACKGROUND OF THE INVENTION 

1. Technical Field: 

The present invention relates generally to an 
improved data processing system, and, in particular, to a 
20 method and apparatus for converting a program or source 
code file from a programming language to a markup 
language . 



2. Description of Related Art: 

25 The World Wide Web (WWW, also known simply as "the 

Web") is an abstract cyberspace of information that is 
physically transmitted across the hardware of the 
Internet. In the Web environment, servers and clients 
communicate using Hypertext Transport Protocol (HTTP) to 

30 transfer various types of data files. Much of this 

information is in the form of Web pages identified by 
unique Uniform Resource Locators (URLs) or Uniform 
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Resource Identifiers (URIs) that are hosted by servers on 
Web sites. The Web pages are often formatted using 
Hypertext Markup Language (HTML) , which is a file format 
that is understood by software applications, called Web 
5 browsers. A browser requests the transmission of a Web 
page from a particular URL, receives the Web page in 
return, parses the HTML of the Web page to understand its 
content and presentation options, and displays the 
content on a computer display device. By using a Web 
10 browser, a user may navigate through the Web using URLs 
to view Web pages. 

As the Web continues to increase dramatically in 
size, companies and individuals continue to look for ways 
to enhance its simplicity while still delivering the rich 
15 graphics that people desire. Although HTML is generally 
the predominant display format for data on the Web, this 
standard is beginning to show its age as its display and 
formatting capabilities are rather limited. If someone 
desires to publish a Web page with sophisticated 
20 graphical effects, the person will generally choose some 
other data format for storing and displaying the Web 
page. Sophisticated mechanisms have been devised for 
embedding data types within Web pages or documents. At 
times, an author of Web content may create graphics with 
25 special data types that require the use of a plug-in. 

The author of Web content may also face difficulties 
associated with learning various data formats. Moreover, 
many different languages other than HTML exist for 
generating presentation data, such as page description 
30 languages. However, some of these languages do not lend 
themselves to use on the Web. Significant costs may be 
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associated with mastering all of these methods. 

On the other hand, the application programming 
interfaces (APIs) of certain operating system 
environments or programming environments are well-known. 

5 Persons who write programs for these APIs have usually 
mastered the display spaces and methods of these APIs. 

A standard has been proposed for Precision Graphics 
Markup Language (PGML) , which is an extensible Markup 
Language (XML) compatible markup language. This standard 

10 attempts to bridge the gap between markup languages and 
page description languages. Markup languages provide 
flexibility and power in structuring and transferring 
documents yet are relatively limited, by their 
generalized nature, in their ability to provide control 

15 over the manner in which a document is displayed. PGML 
incorporates the imaging model common to the PostScript® 
language and the Portable Document Format (PDF) with the 
advantages of XML. However, PGML does not tap the 
existing skills of programmers who are very knowledgeable 

20 about the syntax of many different programming languages 
which are used to define and implement graphical 
presentation capabilities on various computer platforms. 

Therefore, it would useful to have a method for 
adapting well-known APIs in some manner for use as a 

25 Web-based page description language. It would be 

particularly advantageous for the method to provide the 
ability to produce documents that conform with evolving 
markup language processing standards. 
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SUMMARY OF THE INVENTION 

The present invention provides a method and 

5 apparatus for converting programs and source code files 
written in a programming language to equivalent markup 
language files. The conversion may be accomplished by a 
static process or by a dynamic process. In a static 
process, a programming source code file is converted by 

10 an application to a markup language file. A document 
type definition file for a markup language is parsed; a 
source code statement from a source code file is parsed; 
an element defined in the document type definition file 
is selected based on an association between the element 

15 and an identifier of a routine in the source code 

statement; and the selected element is written to a 
markup language file. In a dynamic process, the program 
j_ s executed to generate the markup language file that 
corresponds to the source code file or presentation steps 

20 of the program. The application program is executed; a 
document type definition file for a markup language is 
provided as input; an element defined in the document 
type definition file is selected based on a routine 
called by the application program; and the selected 

25 element is written to a markup language file. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 

5 invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 

10 Figure 1 is a pictorial representation depicting a 

data processing system in which the present invention may 
be implemented in accordance with a preferred embodiment 
of the present invention; 

Figure 2 is a block diagram illustrating a data 

15 processing system in which the present invention may be 
implemented; 

Figure 3 is a block diagram depicting a pictorial 
representation of a distributed data processing system in 
which the present invention may be implemented; 
20 Figures 4A-4B is a block diagram depicting a system 

for converting between programming language source code 
files and markup language files; 

Figure 5 is a flowchart depicting a process for 
converting a programming language source code file to a 
25 markup language file; 

Figure 6 is a flowchart depicting a process for 
converting a markup language file into a programming 
language source code file; 

Figure 7 is an example of a DTD for the programming 
30 language markup language; 

Figure 8 is an example of a program in which the 
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program is written in the programming language that may 
be expected within a programming language source code 
file; 

Figures 9A and 9B are examples of generated markup 
5 language files; 

Figures 10A-10B are block diagrams depicting 
software components within an executable environment that 
may support the execution of an application program; 

Figure 11 is a flowchart depicting a process for 
10 dynamically converting a program into a markup language 
file; 

Figure 12 is a flowchart depicting the process 
within an extended API for generating markup language 
statements; 

15 Figure 13 is a block diagram depicting a Java 

run-time environment that includes a programming language 
to markup language converter application; 

Figure 14 is an example of an extended graphics 
class; 

20 Figures 15A-15E is an example of a DTD for the Java 

graphics markup language; 

Figures 16A-16B is a list providing examples of 

methods within the graphics class that are supported 

within the Java graphics markup language DTD; 
25 Figure 17 is a portion of a Java graphics markup 

language DTD; 

Figure 18 is a portion of a Java program that 

invokes methods within the graphics class of a Java 

Virtual Machine; and 
30 Figure 19 is an example of a markup language file 

that uses the Java Graphics Markup Language. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

5 

With reference now to the figures, Figure 1, a 
pictorial representation depicts a data processing system 
in which the present invention may be implemented in 
accordance with a preferred embodiment of the present 

10 invention. A personal computer 100 is depicted which 

includes a system unit 110, a video display terminal 102, 
a keyboard 104, storage devices 108, which may include 
floppy drives and other types of permanent and removable 
storage media, and mouse 106. Additional input devices 

15 may be included with personal computer 100. Personal 
computer 100 can be implemented using any suitable 
computer, such as an IBM Aptiva™ computer, a product of 
International Business Machines Corporation, located in 
Armonk, New York. Although the depicted representation 

20 shows a personal computer, other embodiments of the 

present invention may be implemented in other types of 
data processing systems, such as network computers, Web 
based television set top boxes, Internet appliances, etc. 
Computer 100 also preferably includes a graphical user 

25 interface that may be implemented by means of systems 

software residing in computer readable media in operation 
within computer 100. 

With reference now to Figure 2, a block diagram 
illustrates a data processing system in which the present 

30 invention may be implemented. Data processing system 200 
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is an example of a client computer. Data processing 
system 200 employs a peripheral component interconnect 
(PCI) local bus architecture. Although the depicted 
example employs a PCI bus, other bus architectures such as 
5 Micro Channel and ISA may be used. Processor 202 and main 
memory 204 are connected to PCI local bus 206 through PCI 
bridge 208. PCI bridge 208 also may include an integrated 
memory controller and cache memory for processor 202. 
Additional connections to PCI local bus 206 may be made 
10 through direct component interconnection or through add-in 
boards. In the depicted example, local area network (LAN) 
adapter 210, SCSI host bus adapter 212, and expansion bus 
interface 214 are connected to PCI local bus 206 by direct 
component connection. In contrast, audio adapter 216, 
15 graphics adapter 218, and audio/video adapter 219 are 

connected to PCI local bus 206 by add-in boards inserted 
into expansion slots. Expansion bus interface 214 
provides a connection for a keyboard and mouse adapter 
220, modem 222, and additional memory 224. SCSI host bus 
20 adapter 212 provides a connection for hard disk drive 226, 
tape drive 228, and CD-ROM drive 230. Typical PCI local 
bus implementations will support three or four PCI 
expansion slots or add-in connectors. 

An operating system runs on processor 202 and is used 
25 to coordinate and provide control of various components 
within data processing system 200 in Figure 2. The 
operating system may be a commercially available operating 
system such as OS/2, which is available from International 
Business Machines Corporation. "OS/2" is a trademark of 
30 International Business Machines Corporation. An object 
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oriented programming system such as Java may run in 
conjunction with the operating system and provides calls 
to the operating system from Java programs or applications 
executing on data processing system 200. "Java'' is a 
5 trademark of Sun Microsystems , Inc. Instructions for the 
operating system, the object-oriented operating system, 
and applications or programs are located on storage 
devices, such as hard disk drive 226, and may be loaded 
into main memory 204 for execution by processor 202. 

10 Those of ordinary skill in the art will appreciate 

that the hardware in Figure 2 may vary depending on the 
implementation. Other internal hardware or peripheral 
devices, such as flash ROM (or equivalent nonvolatile 
memory) or optical disk drives and the like, may be used 

15 in addition to or in place of the hardware depicted in 
Figure 2. Also, the processes of the present invention 
may be applied to a multiprocessor data processing 
system. 

For example, data processing system 200, if 
20 optionally configured as a network computer, may not 

include SCSI host bus adapter 212, hard disk drive 226, 
tape drive 228, and CD-ROM 230. In that case, the 
computer, to be properly called a client computer, must 
include some type of network communication interface, 
25 such as LAN adapter 210, modem 222, or the like. As 
another example, data processing system 200 may be a 
stand-alone system configured to be bootable without 
relying on some type of network communication interface, 
whether or not data processing system 200 comprises some 
30 type of network communication interface. As a further 
example, data processing system 200 may be a Personal 
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Digital Assistant ( PDA) device which is configured with 
ROM and/or flash ROM in order to provide non-volatile 
memory for storing operating system files and/or 
user-generated data. 

5 The depicted example in Figure 2 and above-described 

examples are not meant to imply architectural 
limitations . 

With reference now to Figure 3, a block diagram 
depicts a pictorial representation of a distributed data 

10 processing system in which the present invention may be 
implemented. Distributed data processing system 300 is a 
network of computers in which the present invention may be 
implemented. Distributed data processing system 300 
contains a network 302, which is the medium used to 

15 provide communications links between various devices and 
computers connected together within distributed data 
processing system 300. Network 302 may include permanent 
connections, such as wire or fiber optic cables, or 
temporary connections made through telephone connections. 

20 In the depicted example, a server 304 is connected to 

network 302 along with storage unit 306. In addition, 
clients 308, 310, and 312 also are connected to a network 
302. These clients 308, 310, and 312 may be, for example, 
personal computers or network computers. For purposes of 

25 this application, a network computer is any computer, 

coupled to a network, which receives a program or other 
application from another computer coupled to the network. 
In the depicted example, server 304 provides data, such as 
boot files, operating system images, and applications to 

30 clients 308-312. Clients 308, 310, and 312 are clients to 
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server 304. Distributed data processing system 300 may 
include additional servers, clients, and other devices not 
shown. In the depicted example, distributed data 
processing system 300 is the Internet with network 302 

5 representing a worldwide collection of networks and 
gateways that use the TCP/IP suite of protocols to 
communicate with one another. At the heart of the 
Internet is a backbone of high-speed data communication 
lines between major nodes or host computers, consisting of 

10 thousands of commercial, government, educational and other 
computer systems that route data and messages. Of course, 
distributed data processing system 300 also may be 
implemented as a number of different types of networks, 
such as for example, an intranet, a local area network 

15 (LAN), or a wide area network (WAN). Figure 3 is intended 
as an example, and not as an architectural limitation for 
the present invention. 

Internet, also referred to as an "internetwork", is a 
set of computer networks, possibly dissimilar, joined 

20 together by means of gateways that handle data transfer 

and the conversion of messages from the sending network to 
the protocols used by the receiving network (with packets 
if necessary) . When capitalized, the term "Internet" 
refers to the collection of networks and gateways that use 

25 the TCP/IP suite of protocols. 

Currently, the most commonly employed method of 
transferring data over the Internet is to employ the World 
Wide Web environment, also called simply "the Web". Other 
Internet resources exist for transferring information, 

30 such as File Transfer Protocol (FTP) and Gopher, but have 
not achieved the popularity of the Web. In the Web 
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environment, servers and clients effect data transaction 
using the Hypertext Transfer Protocol (HTTP) , a known 
protocol for handling the transfer of various data files 
(e.g., text, still graphic images, audio, motion video, 

5 etc.). Information is formatted for presentation to a 
user by a standard page description language, the 
Hypertext Markup Language (HTML) . In addition to basic 
presentation formatting, HTML allows developers to specify 
"links" to other Web resources, usually identified by a 

10 Uniform Resource Locator (URL) . A URL is a special syntax 
identifier defining a communications path to specific 
information. Each logical block of information accessible 
to a client, called a "page" or a "Web page", is 
identified by a URL. 

15 The URL provides a universal, consistent method for 

finding and accessing this information, not necessarily 
for the user, but mostly for the user's Web "browser". A 
browser is a software application for requesting and 
receiving content from the Internet or World Wide Web. 

20 Usually, a browser at a client machine, such as client 308 
or data processing system 200, submits a request for 
information identified by a URL. Retrieval of information 
on the Web is generally accomplished with an 
HTML-compatible browser. The Internet also is widely used 

25 to transfer applications to users using browsers. With 
respect to commerce on the Web, consumers and businesses 
use the Web to purchase various goods and services. In 
offering goods and services, some companies offer goods 
and services solely on the Web while others use the Web to 

30 extend their reach. Information about the World Wide Web 
can be found at the Web site of the World Wide Web 
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Consortium at http://www.w3.org. 

With reference now to Figures 4A-4B, a block diagram 
depicts a system for converting between programming 
language source code files and markup language files. 
5 Converter 400 provides functionality for converting 
between program language source code files and markup 
language files. Converter 400 accepts as input a Program 
Language Markup Language (PLML) Document Type Definition 
(DTD) file. 

10 A DTD file contains the rules for applying markup 

language to documents of a given type. It is expressed 
by markup declarations in the document type declaration. 
The declaration contains or points to markup declarations 
that provide a grammar for a class of documents. The 

15 document type declaration can point to an external subset 
(a special kind of external entity) containing markup 
declarations, or can contain the markup declarations 
directly in an internal subset, or can do both. The DTD 
for a document consists of both subsets taken together. 

20 In other words, a DTD which provides a grammar, a body of 
rules about the allowable ordering of a document's 
"vocabulary" of element types, is found in declarations 
within a set of internal and external sources. In some 
instances, the DTD for a particular document may be 

25 included within the document itself. 

Although the examples are provided using XML 
(extensible Markup Language), certain other markup 
languages that are compatible with the Standard 
Generalized Markup Language (SGML) family of languages 

30 may be used to implement the present invention. The 
SGML-compatible language should offer Document Type 
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Definition (DTD) support so that the syntax and meaning 
of the tags within the system may be flexibly changed. 
The input file does not necessarily have to be a DTD as 
long as the input file has the ability to flexibly 
5 specify the grammar or syntax constructs of a language 
for input into the converter. For example, although 
Hypertext Markup Language (HTML) is within the SGML 
family of languages, it does not offer DTD support and 
does not have the flexibility necessary for the present 

10 invention. 

PLML is an XML-compatible language for a particular 
type of programming language. Multiple DTDs may be 
specified so that a data processing system has at least 
one DTD per programming language. 
15 More information about XML may be found in DuCharme, 

XML: The Annotated Specification, January 1999, herein 
incorporated by reference. 

In the example of Figure 4A, converter 400 
references PLML DTD file 402 as an external entity. 
20 Converter 400 uses the grammar in PLML DTD file 402 to 
generate a file that is consistent with the grammar 
within PLML DTD file 402. 

Converter 400 also accepts as input a programming 
language source code file that contains programming 
25 language statements that are to be converted or 

translated. Using PLML DTD file 402 as a guide for 
translating programming language statements in 
programming language source code file 404, converter 400 
generates markup language file 406, which is essentially 
30 a markup language document. 

Each markup language document has both a logical and 
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a physical structure. Physically, the document is 
composed of units called entities. An entity may refer 
to other entities to cause their inclusion in the 
document. Logically, the document is composed of 
5 declarations, elements, comments, character references, 
and processing instructions, all of which are indicated 
in the document by explicit markup. Converter 400 may 
output a markup language document that consists of a 
single entity or file or, alternatively, multiple 
10 entities in multiple files. Examples of a DTD, source 

code file, and markup language file are further described 
below. 

Figure 4B shows PLML-MLPL converter 400 operating in 
a "reverse" manner with respect to Figure 4A. Converter 

15 400 accepts PLML DTD file 402 as input in a manner 
similar to Figure 4A. However, in this example, 
converter 400 accepts markup language file 410 as input 
and generates programming language source code file 412 
as output. Converter 400 is able to "reverse" the 

20 direction of inputs and outputs based on the association 
between a programming language and a markup language 
provided by the PLML DTD file. The association between 
the programming language and the markup language through 
the DTD file is described in more detail further below. 

25 Converter 400 may operate in one of two manners. In 

the first method, a static conversion process may read 
programming language source code file 404 or markup 
language file 410, depending on the direction of the 
conversion, and parse each statement within the input 

30 files on an individual basis. In the second method, a 
dynamic conversion process executes programming language 
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source code file 404 in an interpretive process that 
generates markup language output as a consequence of the 
execution of the programming language code. 
Alternatively, converter 400 provides a special execution 
5 environment for dynamically converting the calls within 
an executable file compiled from programming language 
source code file 404. Each of these methods of 
conversion are explained in further detail below. 

With reference now to Figure 5, a flowchart depicts 

10 a process for converting a programming language source 

code file to a markup language file. The method depicted 
in Figure 5 is similar to that described with respect to 
Figure 4A. The process begins with PLML-MLPL converter 
reading the PLML DTD file (step 502) . The converter 

15 parses the DTD file into an internal data structure (step 
504) . Parsing a DTD into an internal data structure such 
as an object tree is well known in the art. The 
converter opens a markup language file and writes a 
prolog to the markup language file (step 506) . The 

20 converter then opens the programming language source code 
file in order to obtain programming language source code 
statements that will be converted to markup language 
statements (step 508) . 

The converter then reads a source code statement 

25 (step 510) and uses the PLML element in the previously 

generated internal data structure that corresponds to the 
function, method, procedure, or API within the source 
code statement (step 512) . An API is one or more 
routines, subroutines, functions, methods, procedures, 

30 libraries, classes, object-oriented objects, or other 
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callable or invokable software objects used by an 
application program or other software object to direct 
the performance of procedures by the computer's operating 
system or by some other software object. Using the 
5 information in the corresponding PLML element, the 

converter generates an element with content derived from 
the source code statement (step 514) . The content is 
derived from the source code statement by parsing the 
source code statement according to well known methods in 

10 the art. The converter then outputs the generated markup 
language element to the markup language file (step 516) . 
A determination is then made as to whether more source 
code statements are in the programming language source 
code file that need to be processed into markup language 

15 statements (step 518). If so, then the process branches 
back to step 510 to repeat the process for another source 
code statement. If not, then the converter concludes the 
markup language file by writing the appropriate 
terminating tags or information (step 520) . 

20 With reference now to Figure 6, a flowchart depicts 

a process for converting a markup language file into a 
programming language source code file. The process 
depicted in Figure 6 is similar to the process discussed 
with respect to Figure 4B. The process begins with the 

25 PLML converter reading the PLML DTD file (step 602) . The 
converter parses the DTD file into internal data 
structures, such as an object tree representing the 
hierarchy of the elements within the DTD file (step 604) . 
The converter then opens the markup language file in 

30 order to use the markup language file as a source of 

Input for generation of the programming language source 
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code file (step 606) . 

The converter reads an element from the markup 
language file (step 608) and uses the stored PLML element 
within the internal data structure that corresponds to 

5 the inputted element from the markup language file that 
is currently being processed (step 610) . Using the 
previously stored, corresponding PLML element with its 
associated information concerning the correspondence 
between PLML elements and source code statements, the 

10 converter generates a source code statement with content 
from the element currently being processed (step 612) . 
The converter then outputs the generated source code 
statement to the source code file (step 614) . A 
determination is then made as to whether there are other 

15 elements within the markup language file that need to be 
processed (step 616) . If so, then the process branches 
back to step 608 and repeats the process for another 
element within the markup language file. If not, then 
the converter concludes the source code file (step 618) . 

20 With reference now to Figure 7, an example of a DTD 

for the programming language markup language is provided. 
Entity 702 provides a root entity for a PLML document. 
Element 704 provides a root element for a PLML document. 
Element 706 provides a markup language element that 

25 corresponds to a functionA that may be expected to be 
found within a programming language source code file. 
Element 706 for functionA also shows argl and arg2 as the 
arguments that may be expected to be found in a source 
code statement when a source code statement is parsed and 

30 found to contain a call to functionA. The CDATA 
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attribute type is a character string attribute type that, 
in this case, is required to be found in a markup 
language element for functionA. Element 706 is written 
in such a way that argl and arg2 must appear as attribute 
5 types describing the corresponding function call 

arguments for a source code statement that contains a 
call to functionA. Element 708 is similar to element 
706. Element 708 provides for the element within a 
markup language file that corresponds to a call to 
10 functionB within a source code statement that may be 
expected to be found in a programming language source 
code file. Element 708 contains a CDATA attribute type 
named argl for providing the argument value of the 
argument in the source code statement containing a call 
15 to functionB. 

With reference now to Figure 8, an example of a 
program is provided in which the program is written in 
the programming language that may be expected within a 
programming language source code file. Program 800 
20 contains a simple program of a few statements. 

Statements 802 are initial program statements that 
commence and initiate the body of the program. Statement 
804 contains a call to functionA and statement 806 
contains a call to functionB in a manner which 
25 corresponds to the declaration of elements 706 and 708 in 
Figure 7 . 

With reference now to Figures 9A and 9B, examples of 
generated markup language files are provided. These 
markup language files may have been generated using a 
30 process similar to that described in Figures 4A and 5. A 
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PLML DTD file, similar to that shown in Figure 7, may 
have been used as input to a converter that read a 
programming language source code file, similar to that 
shown in Figure 8, in order to generate the markup 
5 language shown as markup language statements 900 and 920 
in the markup language files of Figures 9A and 9B. 

Statements 902 provide the prolog for the markup 
language file or document. The prolog provides 
information about the document, such as the version of 

10 the markup language being used, the name of the file that 
contains the DTD, etc. Statement 904 is the start tag 
for the content of the markup language file. Statements 
906 are comments which contain content that is identical 
to statements 802 in Figure 8 that describe the 

15 declaration and initialization of the program shown 

within Figure 8. Statement 908 provides an element for 
functionA that corresponds to the call to functionA in 
statement 804 in the program shown in Figure 8. 
Statement 910 shows an element for functionB that 

20 corresponds to the call to functionB in the program of 

Figure 8. Statements 908 and 910 also contain attributes 
providing the values of arguments that correspond to the 
values of the arguments in the function calls of the 
program in Figure 8. Statement 912 contains the 

25 conclusion of the program in Figure 8. Statement 914 
provides the end tag for the content of the markup 
language file. 

Figure 9B shows an example of a markup language file 
that has been converted from program 800 shown in Figure 

30 8. The markup language file of Figure 9B is similar to 
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the markup language file of Figure 9A except that the 
markup language file of Figure 9B does not contain the 
declaration and initialization statements of computer 
program 800 as comment statements in the markup language 
5 file in a manner similar to those shown in Figure 9A. 

Statements 922 provide the prolog for the markup 
language file. Statement 924 provides the start tag for 
the content for the markup language file. Statement 926 
provides an element and an attribute list for functionA 

10 similar to the call to functionA in computer program 800. 
Statement 928 provides an element and an attribute list 
for functionB similar to the call to functionB and 
statement 806 in computer program 800. Statement 930 
provides the end tag to the markup language file. 

15 The differences between Figures 9A and 9B are minor 

from the perspective of the markup language file. Figure 
9A contains additional comment statements that are not 
found in Figure 9B. These comment statements do not 
affect the parsing of the markup language file. However, 

20 by placing some of the source code statements as comment 
statements in the markup language file, a converter which 
converts the markup language file to a programming 
language source code file in a "reverse" direction may 
use these comment statements to regenerate the majority 

25 of the program that was the origin for the markup 

language file. In other words, these comment statements 
may provide for a complete conversion cycle from a 
programming language source code file to a markup 
language file and back to a programming language source 

30 code file without the loss of any information necessary 
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to compile the programming language source code file. 

Rules for the inclusion of these other statements 
within a markup language file may be used to determine 
which portions of the original programming language 
5 source code file should be included during a conversion 
process to a markup language file. These rules may vary 
depending upon the programming language and the markup 
language being used in the conversion process. For 
example, statements 804 and 806 in Figure 8 contain the 

10 use of a temporary variable named "TEMP". However, 

during the conversion process of computer program 800 
into markup language file 900, information concerning the 
use of the temporary variable was dropped after a 
determination that inclusion of other information 

15 concerning the temporary variable was not necessary. 

Alternatively, the use of the temporary variable within 
computer program 800 may have been stored within 
additional comment statements in markup language file 
900. 

20 Figures 5 and 6 described a method for a static 

conversion process for programming language source code 
files and markup language files. As an alternative 
method, a converter may generate a markup language file 
using a dynamic conversion process that will be described 

25 with respect to Figures 10A-14. 

With reference now to Figures 10A-10B, block 
diagrams depict software components within an executable 
environment that may support the execution of an 
application program. In Figure 10A, operating system 

30 1000 contains API 1002 that may be called by executable 
application program 1004 during the course of its 
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execution. In this manner, executable application 1004 
is supported by API 1002 and operating system 1000. 

In Figure 10B, operating system 1010 has API 1012 

and extended API 1014 that may be called by executable 

5 application program 1016. Extended API 1014 may provide 
an API that is similar to API 1012 yet also provides 
additional capabilities that are not necessary in a 
standard execution environment. In this manner, 
executable application program 1016 may be supported 

10 during its execution of a dynamic conversion process that 
uses the additional functionality in extended API 1014. 

With reference now to Figure 11, a flowchart depicts 
a process for dynamically converting a program into a 
markup language file. The process begins when the 

15 application program is loaded into an execution 
environment with extended APIs (step 1102) . The 
execution of the program is initiated (step 1104), and 
the procedures within the executing program invoke the 
procedures within or that constitute the extended API 

20 (step 1106) . The extended API procedures then generate 
the markup language statements (step 1108) . Steps 1106 
and 1108 essentially describe steps that may be invoked 
multiple times during a process of generating markup 
language statements. The program then completes its 

25 execution (step 1110) . In this manner, the executable 
program is allowed to execute in a normal fashion 
although within an environment with extended APIs. The 
extended APIs then provide the functionality for 
generating the markup language statements in a manner 

30 that is further described below. 
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With reference now to Figure 12 , a flowchart depicts 
the process within an extended API for generating markup 
language statements. The process begins when the 
executable program contains a procedure that calls the 
5 API procedure in the extended API environment (step 
1202) . Each API procedure within the extended API 
environment is responsible for parsing a PLML DTD (step 
1204) . In this case, the burden of locating the 
appropriate PLML element that corresponds to the API 

10 procedure is placed within the API procedure itself. The 
location of the PLML DTD file may be obtained through a 
global environment variable or some other well known 
method for providing global information to multiple 
procedures. Alternatively, the PLML DTD may have been 

15 parsed into an internal data structure, such as an object 
tree, and each API procedure is responsible for 
traversing the object tree or other internal data 
structure to locate the appropriate PLML element needed 
for the API procedure. 

20 The API procedure then gets the syntax of its 

corresponding PLML element from the appropriate location 
(step 1206) . The API procedure generates a PLML 
statement with appropriate attributes that correspond to 
the parameters that have been passed into the API 

25 procedure during the API procedure call (step 1208) . 

Once the PLML statement is generated, the API procedure 
may optionally perform its normal execution sequence that 
would be found in the standard API without the extended 
API functionality for generating a markup language 

30 statement (step 1210) . The API procedure then completes 
its execution (step 1212) and returns to the calling 
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procedure of the executable program. The procedure 
within the executable program that invoked the API then 
continues with its execution within the normal control 
flow of the executable program (step 1214) . In this 

5 manner, the executable program is not modified in order 
to produce the markup language output. The extended API 
provides an interface similar to the standard API while 
including additional functionality that generates the 
desired markup language output. This additional 

10 functionality is described in further detail with 
specific examples in Figures 13-19. 

With reference now to Figure 13, a block diagram 
depicts a Java run-time environment that includes a 
programming language to markup language converter 

15 application. System 1300 contains a platform specific 

operating system 1302 that supports the execution of Java 
Virtual Machine (JVM) 1304. JVM 1304 contains Graphics 
classes 1306 which is a set of classes that provide 
graphic contexts that allow an application to draw and 

20 paint images and graphical objects on various devices. 
The Graphics classes may be provided as part of the JDK 
AWT classes. 

In this case, the system provides conversion from 
the Java programming language to the Java Graphics Markup 

25 Language (JGML) . Java- JGML converter application 1308 
runs within JVM 1304. Converter 1308 is written in the 
Java language and may be executed within JVM 1304 through 
interpretation or just-in-time compilation. Converter 
1308 contains extended graphics classes 1310 that provide 

30 additional functionality to graphics classes 1306 in a 
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manner similar to the components depicted in Figure 10B 
and described in the methods of Figures 11-12. The 

technique of extending a Java class is well known in the 
art . 

5 Converter application 1308 is written in the Java 

language yet converts a Java language program into an 
equivalent JGML file. In a static conversion process, 
converter 1308 reads Java text/graphics program file 1312 
and parses the Java statements within the file in a 

10 manner similar to the process described with respect to 
Figures 4A and 5. JGML DTD file 1316 provides the 
grammar of the JGML that is required during the 
conversion process. Converter 1308 uses the DTD file and 
program file to generate JGML statements as output to 

15 JGML equivalent text/graphics file 1314. 

When converter 1308 is used to convert a Java 
program to a markup language file in a static conversion 
process, converter 1308 does not require the additional 
functionality provided within extended graphics classes 

20 1310. Converter 1308 steps through the Java language 

statements in program file 1312 and generates equivalent 
markup language statements that are placed into markup 
language file 1314. 

Alternatively, converter 1308 may dynamically 

25 convert the Java language statements in program file 1312 
into markup language statements in markup language file 
1314 in a manner similar to that described in Figures 4B, 
6, 10B, 11, and 12. In a dynamic conversion process 
within system 1300, JVM 1304 may load the Java program 

30 within Java program file 1312 in combination with 
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extended graphics classes 1310. Extended graphics 
classes 1310 may be loaded simultaneously with the Java 
program in program file 1312 or may be included within 
program file 1312 as a separate class or set of classes. 
5 JVM 1304 then interprets the loaded program in the 
standard manner. By providing the additional 
functionality of Java-to-JGML conversion within extended 
graphics classes 1310, the Java program within program 
file 1312 enables its own conversion to a markup language 

10 file. In this manner, the Java program within program 
file 1312 may be considered its own conversion 
application. This manner of execution is described in 
further detail with respect to Figures 14-19. 

With reference now to Figure 14, an example of an 

15 extended graphics class is provided. Extended graphics 
class 1400 is similar to the extended class depicted as 
extended graphics class 1310 in Figure 13. Extended 
class 1400 provides portions of pseudocode that describe 
some of the functionality that may be required to convert 

20 a Java program. Line 1402 declares that the class 

extends the Graphics class within a Java Virtual Machine. 
Method 1404 provides functionality for a drawLine method 
that may be expected to be found within the graphics 
class within the JVM. In a manner similar to that 

25 described with respect to Figure 12, the statements in 
method 1404 provide the functionality for generating the 
desired markup language statements. Line 1406 notes that 
each method within the extended class is responsible for 
parsing the JGML DTD for the proper syntax required by 

30 the method. 
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In this example, line 1406 notes that the drawLine 
method parses and analyzes the JGML DTD for the drawLine 
syntax. Line 1408 shows that a JGML output statement is 
constructed using the syntax for the drawLine method 
5 obtained from the JGML DTD and from the current 

parameters used by the invocation of method 1404, Line 
1410 provides a pseudocode statement for outputting the 
JGML markup language statement to a markup language file. 
Method 1412 contains similar pseudocode for 

10 generating markup language output for a clearRect method 
invocation. Extended class 1400 may contain many other 
examples of methods for converting Java language 
statements to markup language statements. The pseudocode 
within the methods of extended class 1400 may also be 

15 modified so that the methods do not analyze the DTD with 
each invocation but rather refer to a common or global, 
internal data structure that contains the syntax required 
for each element in the JGML grammar. 

In general, the DTD need not contain equivalent 

20 elements for all the Java APIs. Generally, it is enough 
to have equivalent elements in the DTD corresponding to 
the abstract methods in the Java class. In the typical 
Java design, the other methods are internally coded in 
Java using the abstract methods. However, for securing a 

25 performance advantage and ease of programming in the 

markup language, the DTD may have some selected elements 
corresponding to non-abstract methods of Java also. By 
rewriting just the abstract methods of Java to generate 
the markup language, all the Java API's would 

30 automatically get converted to the markup language. 

Figures 16A and 16B contain all the Java Graphics APIs - 
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both abstract and non-abstract. The Java standard 
specifications indicate which of them are abstract and 
which are not. Figures 15A-E contain the DTD elements 
corresponding to almost all the abstract methods and some 
5 additional methods. In some cases , the DTD has merged 
several abstract methods, e.g., the drawlmage methods, 
into one element. In certain cases, a few Java APIs may 
not need to be explicitly converted into markup language 
structures even if they are abstract, and they may be 
10 omitted from the markup language DTD. Hence, there is no 
need for the DTD and the list of Java APIs to be 
identical . 

With reference now to Figures 15A-15E, an example of 
a DTD for the Java graphics markup language is provided. 

15 Each element within the DTD corresponds to a method 
within the Graphics class of the Abstract Windowing 
Toolkit (AWT) in the standard Java Virtual Machine. 

With reference now to Figures 16A-16B, a list 
provides examples of methods within the graphics class 

20 that are supported within the Java graphics markup 

language DTD. A comparison of the methods listed in 
Figures 16A-16B and the elements in the Java graphics 
markup language DTD provides a correspondence between the 
methods and the elements so that the conversion of a Java 

25 language program, which contains these method calls, may 
be converted into appropriate elements within a markup 
language file. 

With reference now to Figure 17, a portion of a Java 
graphics markup language DTD is provided. Element 1702 

30 provides the syntax for a drawLine element that 

corresponds to a drawLine function in the graphics class 
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of a Java Virtual Machine. Element 1704 provides a 
clearRect element that corresponds to the clearRect 
method in the Graphics class of the Java Virtual Machine. 
Element 1702 has associated attribute list 1706 that 
5 provides the syntax for including the parameters for the 
drawLine method within the markup language file. Element 
1704 has associated attribute list 1708 that provides the 
syntax for including the parameters for the clearRect 
method within the markup language file. The syntax of 
10 the portion of the DTD provided within Figure 17 is 

similar to the syntax shown and explained with respect to 
Figure 7. 

With reference now to Figure 18, a portion of a Java 
program that invokes methods within the graphics class of 

15 a Java Virtual Machine is provided. Statement 1802 
invokes the drawLine method with four parameters. 
Statement 1804 invokes the drawLine method a second time 
also with four parameters. Statement 1806 invokes the 
clearRect method with four integer parameters. The 

20 portion of the Java program depicted within Figure 18 is 
similar to the depiction of a program described with 
respect to Figure 8. 

With reference now to Figure 19, an example of a 
markup language file that uses the Java Graphics Markup 

25 Language is provided. Markup language file 1900 has been 
generated with reference to the grammar for the JGLM 
elements shown as DTD portion 1700 in Figure 17 and Java 
language statements 1800 in Figure 18. Line 1902 
corresponds to statement 1802 using the drawLine element 

30 1702. Line 1904 corresponds to statement 1804 using the 
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drawLine element shown as line 1702. Line 1906 
corresponds to statement 1806 using element 1704 for the 
clearRect method invocation. JGML file 1900 may have 
been produced using DTD portion 1700 and program portion 
5 1800 as inputs to a static conversion method or a dynamic 
conversion method as described above with respect to 
Figure 13. 

The advantages of the present invention should be 
apparent in light of the detailed description provided 

10 above. An application written in a programming language 
is translated or converted into a markup language 
document in accordance with a DTD written for this 
purpose. The original application may be converted 
statically by another application by translating source 

15 code statements to markup language statements. 

Alternatively, the original application is translated 
dynamically by executing the original application in an 
execution environment capable of translating API 
invocations to markup language statements. Once an 

20 application is written, the application may be translated 
to a markup language document without requiring the 
knowledge of markup language syntax. The generated 
document then contains the flexibility and power of an 
XML-compatible markup language document that ensures that 

25 the document is easily transferable and translatable yet 
contains graphical capabilities in a well-known syntax. 

It is important to note that while the present 
invention has been described in the context of a fully 
functioning data processing system, those of ordinary 

30 skill in the art will appreciate that the processes of 

the present invention are capable of being distributed in 
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the form of a computer readable medium of instructions 
and a variety of forms and that the present invention 
applies equally regardless of the particular type of 
signal bearing media actually used to carry out the 

5 distribution. Examples of computer readable media 

include recordable-type media such a floppy disc, a hard 
disk drive, a RAM, and CD-ROMs and transmission-type 
media such as digital and analog communications links. 
The description of the present invention has been 

10 presented for purposes of illustration and description, 
but is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 
the art. The embodiment was chosen and described in 

15 order to best explain the principles of the invention, 
the practical application, and to enable others of 
ordinary skill in the art to understand the invention for 
various embodiments with various modifications as are 
suited to the particular use contemplated. 
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CLAIMS : 

What is claimed is: 

5 1. A method of processing a source code statement 

written in a programming language, the method comprising 
the computer-implemented steps of: 

parsing a document type definition file for a markup 
language; 

10 parsing a source code statement from a source code 

file; 

selecting an element defined in the document type 
definition file based on an association between the 
element and an identifier of a routine in the source code 
15 statement ; and 

writing the selected element to a markup language 

file. 

2. The method of claim 1 wherein the source code 
20 statement comprises parameters for the routine and 

wherein the element comprises an attribute list 
corresponding to the parameters. 

3. The method of claim 2 wherein the selected element 
25 written to the markup language file comprises an 

attribute list of values for the parameters passed to the 
routine . 

4. The method of claim 1 wherein the routine is a 
30 procedure, subroutine, function, method, class, or 

software object . 
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5. A method of processing a markup language element, 

the method comprising the computer-implemented steps of: 
parsing a document type definition file for the 
5 markup language; 

parsing a markup language element from a markup 

language file; 

selecting an element defined in the document type 

definition file that is equivalent to the markup language 
10 element from the markup language filer- 
generating a source code statement using an 

identifier of a routine within the selected element; and 
writing the source code statement to an output file. 

15 6. A method of generating a markup language file, the 
method comprising the computer-implemented steps of: 
executing an application program; 

parsing a document type definition file for a markup 
language; 

20 selecting an element defined in the document type 

definition file based on a routine called by the 
application program; and 

writing the selected element to a markup language 

file. 

25 

7. The method of claim 6 wherein the element comprises 
an attribute list corresponding to parameters for the 
routine . 

30 8. The method of claim 6 wherein the selected element 
written to the markup language file comprises an 
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attribute list corresponding to values for the parameters 
passed to the routine. 

9. The method of claim 6 wherein the application 
5 program is written in Java programming language. 

10. The method of claim 9 wherein the routine is an 
extended class method. 

10 11. The method of claim 9 wherein the routine is a 
Graphics class method. 

12. A data processing system for processing a source 
code statement written in a programming language, the 

15 data processing system comprising: 

first parsing means for parsing a document type 
definition file for a markup language; 

second parsing means for parsing a source code 
statement from a source code file; 
20 selecting means for selecting an element defined in 

the document type definition file based on an association 
between the element and an identifier of a routine in the 
source code statement; and 

writing means for writing the selected element to a 
25 markup language file. 

13. The data processing system of claim 12 wherein the 
source code statement comprises parameters for the 
routine and wherein the element comprises an attribute 

30 list corresponding to the parameters. 
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14. The data processing system of claim 13 wherein the 
selected element written to the markup language file 
comprises an attribute list of values for the parameters 
passed to the routine. 

5 

15. The data processing system of claim 12 wherein the 
routine is a procedure, subroutine, function, method, 
class, or software object. 

10 16. A data processing system for processing a markup 

language element, the data processing system comprising: 

first parsing means for parsing a document type 
definition file for the markup language; 

second parsing means for parsing a markup language 
15 element from a markup language file; 

selecting means for selecting an element defined in 
the document type definition file that is equivalent to 
the markup language element from the markup language 
file; 

20 generating means for generating a source code 

statement using an identifier of a routine within the 
selected element; and 

writing means for writing the source code statement 

to an output file. 

25 

17. A data processing system for generating a markup 
language file, the data processing system comprising: 

executing means for executing an application 
program; 

30 parsing means for parsing a document type definition 

file for a markup language; 
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selecting means for selecting an element defined in 
the document type definition file based on a routine 
called by the application program; and 

writing means for writing the selected element to a 
5 markup language file. 

18. The data processing system of claim 17 wherein the 
element comprises an attribute list of parameters for the 
routine . 

10 

19. The data processing system of claim 17 wherein the 
selected element written to the markup language file 
comprises an attribute list of values for the parameters 
passed to the routine. 

15 

20. The data processing system of claim 17 wherein the 
application program is written in Java programming 
language . 

20 21. The data processing system of claim 20 wherein the 
routine is an extended class method. 

22. The data processing system of claim 20 wherein the 
routine is a Graphics class method. 

25 

23. A computer program product in a computer readable 
medium for use in a data processing system for processing 
a source code statement written in a programming 
language, the computer program product comprising: 

30 first instructions for parsing a document type 

definition file for a markup language; 
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second instructions for parsing a source code 
statement from a source code file; 

third instructions for selecting an element defined 
in the document type definition file based on an 
association between the element and an identifier of a 
routine in the source code statement; and 

fourth instructions for writing the selected element 
to a markup language file. 

24. A computer program product on a computer readable 
medium for use in a data processing system for processing 
a markup language element, the computer program product 
comprising: 

first instructions for parsing a document type 
definition file for the markup language; 

second instructions for parsing a markup language 
element from a markup language file; 

third instructions for selecting an element defined 
in the document type definition file that is equivalent 
to the markup language element from the markup language 
file; 

fourth instructions for generating a source code 
statement using an identifier of a routine within the 
selected element; and 

fifth instructions for writing the source code 
statement to an output file. 

25. A computer program product on a computer readable 
medium for use in a data processing system for processing 
a markup language file, the computer program product 
comprising: 
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first instructions for executing an application 
program; 

second instructions for parsing a document type 
definition file for a markup language; 
5 third instructions for selecting an element defined 

in the document type definition file based on a routine 
called by the application program; and 

fourth instructions for writing the selected element to a 
markup language file. 

10 

26. A method of processing a source code statement 
written in a programming language, the method comprising 
the computer-implemented steps of: 

parsing a grammar input file for a markup language; 
15 parsing a source code statement from a source code 

file; 

selecting a language syntax construct defined in the 
grammar input file based on an association between the 
language syntax construct and an identifier of a routine 
20 in the source code statement; and 

writing the selected language syntax construct to a 
markup language file. 
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ABSTRACT OF THE DISCLOSURE 



METHOD AND APPARATUS FOR CONVERTING PROGRAMS AND SOURCE 
5 CODE FILES WRITTEN IN A PROGRAMMING LANGUAGE TO EQUIVALENT 

MARKUP LANGUAGE FILES 



A method and apparatus for converting programs and 

10 source code files written in a programming language to 
equivalent markup language files is provided. The 
conversion may be accomplished by a static process or by 
a dynamic process. In a static process r a programming 
source code file is converted by an application to a 

15 markup language file. A document type definition file 
for a markup language is parsed; a source code statement 
from a source code file is parsed; an element defined in 
the document type definition file is selected based on an 
association between the element and an identifier of a 

20 routine in the source code statement; and the selected 
element is written to a markup language file. In a 
dynamic process, the program is executed to generate the 
markup language file that corresponds to the source code 
file or presentation steps of the program. The 

25 application program is executed; a document type 

definition file for a markup language is provided as 
input; an element defined in the document type definition 
file is selected based on a routine called by the 
application program; and the selected element is written 

30 to a markup language file. 
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924 ^ <piml> 

926 < functionA arg1 ="5" arg2= M 7"/> 

m ^ <functionBarg1= 1, 25'7> 

^ 93Q {~ </plml> 
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<?pimi version = "1.0 ,l ?> 



< ! DOCTYPE plml SYSTEM "plrnl.dtd^ 
§24 ^ <plmE> 

< ! - main prog ram A ( }{ — > 

< ! - integer temp; — > 

< ! - initProg ( ): — > 

m <functionAarg1="5 , arg2= , 7" /> 
m ^ <functionBargl="25" /> 



£12 



914 



^ < / plml = 
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< ? pirn! version = "1 .0'7> 



922 V 



< ! DOCTYPE plml SYSTEM "plml.dtd"> 
m ^ <plmf> 

m <functionAarg1="5"arg2="r7> 
£28 <functionBarg1="2S , 7> 
330 ^ < /plml > 
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1402 publtc class JGML Graphics extends Graphfcs 



public void drawLine (Int xl r in* in x2, Int y2) 



Analyze JGML DTD for "drawLine" syntax 



i 

liS8 Generate JGML output statement with "drawLine* syntax and current parameters 

1410 \ printLine ("<drawLina x1«r + x1 + V yl= V" + yi -\ 

^- + Ty2*r + y2 + T />"); 



1 + V x2=V m + x2 



j^" public vQtd cfearRecttfntx, int y, int width, int height) 



{ 

Analyze JGML DTD for "ctearRecr syntax 

Generate JGML output statement with "clearRect" syntax and current parameters 
printLine { 

^ <cteHrRect x*r + x + T y=Y'" * y + T widths 1 " + width + T height=P + height + T />); 
} 
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<!- Java Graphics Markup Language (JGML) Document Type Definition (DTD) -> 
<!ENTITY % base_conteot_model 

'(copy Area j drawLine | fillRect j drawRect | clearRect 1 

drawRoundRect 1 fillRoundRcct | draw3Drect | fill3Drcct| 

drawOval | fillOval | drawArc j fillArc [ drawPoIyline] 

drawPoLygon J xUlPorygon | drawString | diawChars| 

drawBytes | drawlmage j dispose | finalize | clipRectj 

setClip | setColor | setPaintMode | translate | sctXORMode j 

setFont)*' 

> 

<!ELEMENT jgml %rrae_content_rnodel;> 





<! ELEMENT copyArca 


EMPTY> 


















copyArea 


X 












CDATA 








y ^ 


PT1ATA 








height 


CDATA 








dx 


CDATA 


#REQUIRED 




> 


dy 


CDATA 


^REQUIRED 




<!ELEMENT drawLine 


EMPTY> 








<!ATTLIST 










drawLine 


xl 


CDATA 


^REQUIRED 






yi 


CDATA 


#REQUIRED 






x2 


CDATA 


#REQUIRED 




> 


y2 


CDATA 


#REQUIRED 




<!ELEMENT fillRect 


EMPTY> 








<!ATTLIST 










fillRect 


X 


CDATA 


^REQUIRED 






y 


CDATA 


^REQUIRED 






width 


CDATA 


^REQUIRED 




> 


height 


CDATA 


#REQUTRED 




<! ELEMENT drawRect 


EMPTY> 








<!ATTLIST 










drawRect 


X 


CDATA 


#REQUIRDD 


iij 




y 


CDATA 


#REQUIRED 






width 


CDATA 


^REQUIRED 




> 


height 


CDATA 


^REQUIRED 




<! ELEMENT clearRect 


EMPTY> 








<!ATTLIST 










clearRect 


X 


CDATA 


^REQUIRED 








CDATA 


#REQUIRED 






width 


CDATA 


#RE QUIRED 






height 


CDATA 


#REQUIRED 



> 
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<! ELEMENT drawRoundRect 
<!ATTLIST 

drawRoundRect 



<! ELEMENT fiURoundRect 
<!ATTLIST 

fiURoundRect 



<!ELEMENT draw3DRect 
<!ATIXIST 

draw3DRect 



<!ELEMENT filDDRecfc 
<JATTUST 

filI3DRect 



<! ELEMENT drawOval 
OATTLIST 

drawOval 



<!ELEMENTfiilOval 
<!ATTLIST 

fiUOval 



EMPTY> 



y 

width 
height 
areWidth 
aicHeight 

EMPTY> 



y 

width 
height 
areWidth 
arcHeight 

EMPTY> 



y 

width 
height 
raised 

EMPTY> 



y 

width 
height 
raised 

EMPTY> 

x 

y 

width 
height 

EMPTY> 

x 

y 

width 
height 



CDATA 
CDATA 
CDATA 
CDATA 
CDATA 
CDATA 



CDATA 
CDATA 
CDATA 
CDATA 
CDATA 
CDATA 



CDATA 
CDATA 
CDATA 
CDATA 
CDATA 



CDATA 
CDATA 
CDATA 
CDATA 
CDATA 



CDATA 
CDATA 
CDATA 
CDATA 



CDATA 
CDATA 
CDATA 
CDATA 



^REQUIRED 
^REQUIRED 
REQUIRED 
#REQUIRED 
^REQUIRED 
^REQUIRED 



#REQUIRED 
^REQUIRED 
^REQUIRED 
#REQUIRED 
^REQUIRED 
#REQUTR£D 



#REQIHRED 
#REQUCRJBD 
#R£QUIR£D 
#REQUIRED 
#REQUIRED 



^REQUIRED 
^REQUIRED 
^REQUIRED 
^REQUIRED 
#REQUIRED 



^REQUIRED 
#REQUIRED 
^REQUIRED 
#REQUIRED 



^REQUIRED 
^REQUIRED 
^REQUIRED 
^REQUIRED 
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<! ELEMENT drawArc 


EMPTY> 






<!ATTLIST 








diawArc 


X 


CDATA 






y 


CDATA 






width 


CDATA 






height 


CDATA 






startAngle 


CDATA 




> 


arcAnglc 


CDATA 




<f ELEMENT ffllAre 


EMPTY> 






<JATrLIST 








fill Aw* 


X 


CDATA 






y 


CDATA 






width 


CDATA 






height 


CDATA 






startAngle 


CDATA 




> 


arcAngle 


CDATA 


O 




hMJrxi> 






<!ATTLIST 








drawPolyLine 


xPoints 


CDATA 






yPoints 


CDATA 




> 


nPoints 


CDATA 




<!ELEMENT diawPolygon 


EMPTY> 






OATTLIST 








drawPoIygoc 


xPoints 


CDATA 






yPoims 


CDATA 






nPoints 


CDATA 




> 


P 


CDATA 




<!ELEMENT fiflPolygon 


EMPTY> 






<!ATTXIST 








fiHPolygon 


xPoints 


CDATA 






yPoints 


CDATA 






nPoints 


CDATA 




> 


Polygon 


CDATA 




<!ELEMENT drawString 


EMPTY> 






<!ATTLIST 








drawString 


str 


CDATA 






X 


CDATA 






y 


CDATA 



^REQUIRED 
^REQUIRED 
^REQUIRED 
#REQIHRED 
^REQUIRED 
^REQUIRED 



^REQUIRED 
^REQUIRED 
^REQUIRED 
^REQUIRED 
^REQUIRED 
^REQUIRED 



^REQUIRED 
^REQUIRED 
^REQUIRED 



^IMPLIED 
^IMPLIED 
IMPLIED 
IMPLIED 



IMPLIED 
^IMPLIED 
#IMPLIED 
IMPLIED 



#REQUIRED 
^REQUIRED 
^REQUIRED 
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<!ELEMENT drawChars 


ClVJx 1 I' 






<!ATTLIST 










data 


CDATA 


^REQUIRED 




offset 


CDATA 


^REQUIRED 




length. 


CDATA 


^REQUIRED 




X 


CDATA 


^REQUIRED 


> 


y 


CDATA 


^REQUIRED 


<[ ELEMENT drawBytes 


"RTVjnyrvs. 

ElVLri I > 






<!ATTLIST 








drawBvtes 


onset 


CDATA 


^REQUIRED 




length 


CDATA 


^REQUIRED 




X 


CDATA 


^REQUIRED 


> 


y 


CDATA 




<! ELEMENT drawlmage 


EMPTY> 






<!ATTLIST 








drawlmage 


irag 


CDATA 


^REQUIRED 


P 


X 


CDATA 


IMPLIED 




y 


CDATA 


^IMPLIED 






CDATA 


#IMPLIED 






CDATA 


^IMPLIED 




dxl 


CDATA 


#IMPLIED 


if* 


dyJ 


CDATA 


^IMPLIED 




dx2 


CDATA 


#IMPLIED 




dy2 


CDATA 


^IMPLIED 




sxl 


CDATA 


#IMPLIED 




syl 


CDATA 


#IMPUED 




sx2 


CDATA 


#IMPLIED 




sy2 


CDATA 


3HMPLEED 




bgcolor 


CDATA 


#IMPLIED 


% s > 


observer 


CDATA 


^REQUIRED 


Iff <ELEMENT dispose 


EMPTY> 






<! ELEMENT finalize 


EMPTY> 






™' <!ELEMENT clipRect 


EMPTY> 






if! <!ATTLIST 








ifl clipRect 


X 


CDATA 


^REQUIRED 




y 


CDATA 


#REQUIRED 




width 


CDATA 


^REQUIRED 


> 


height 


CDATA 


#REQUIRED 
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<!ELEMENT setCIip 
<!ATTUST 

setClip 



<!ELEMENT setColor 
<£ATTLIST 

seColor 
<!ELEMENT setPaintmode 
<!ELEMENT translate 
<!ATTLIST 

translate 



EMPTY> 
x 

y 

width 
height 
clip 

EMPTY> 

color 

EMPTY> 

EMPTY> 



CDATA 
CDATA 
CDATA 
CDATA 
CDATA 



CDATA 



CDATA 
CDATA 



<ELEMENT setXORMode EMPTY> 
<1ATTL3ST 

setXORMode cl CDATA 

> 

<!ELEMENT setFont EMPTY> 
<!ATTLIST 

setFont font CDATA 

> 

<!~ End of DTD for Java Graphics Markup Language --> 



#IMPUED 
#IMPLIED 
#IMPLIED 
^IMPLIED 
#MPHED 



#REQUIRED 



^REQUIRED 
^REQUIRED 



^REQUIRED 



^REQUIRED 
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• cJfiarBecj (int int, int, int) 

SSce* 18 SP6Cified rectanBle ffl^O ^ with the background color of the current drawing 

• cJip_Becj(int int int int) 

Intersects the current clip with the specified rectangle 

• szm&Ba (int int Int, Int, Int, int) 

Copies an area of the component by a distance specified by dx and dy. 
•steate (} 

Creates a new Graphics object that is a copy ofth is Graphics object, 
•cigaistint.int.intint) r * 

Creates a new Graphics object based on this Graphics object but with a new translation and 
cup area. 

#OJ£BQ£e.() 

• Disposes of this graphics context and releases any system resources that it is using 

• QjBw3Drect (int, int, int, int, boolean) 

Draws a 3-D highlighted outline of the specified rectangle. 

• drawAro (int int int int int, int) 
Draws the outline of a circular or elliptical arc covering the specified rectangle. 

(bytef }, int, int, int int) 

Draws the text given by the specified byte array, using this graphics context's current font and 
color. 

• drawChgrefrharj], i n t, int, int, int) 

Draws the text given by the specified character array, using this graphics context's current font 
and color. 

• drawirnags (image, Intint, Color, ImageObserver) 

Draws as much of the specified image as Is currently available. 

• tifawjrnage (image, int, int, int, int, Color, ImageObserver) 

Draws as much of the specified image as has already been scaled to fit inside the specified 
rectangle. r 

• drawlrnage (Image, int int. int int ImageObserver) 

Draws as much of the specified image as has already been scaled to fit inside the specified 
rectangle. 

• drawlrna g e , (Image, int int, int, int, int int, int, int, Color, ImageObserver) 

Draws as much of the specified area of the specified image as is currently available, scaling it 
on the fly to fit inside the specified area of the destination drawable surface 

• drawlmagg (Image, int, int, int, int, int int int, int ImageObserver) 

Draws as much of the specified area of the specified image as is currently available, scaling it 
on She fly to fit inside the specified area of the destination drawable surface. 

• sTBJfliUns (int, int, int, int) 

Draws a fine using the current color, between the points (x1 , y 1) and (x2, y2) in this graphics 
context" coordinate system. 

• drawOvaj (int, int, int int) 

Draws the outline of an oval. 

• tirawFolygon Ont[ ], int[ ], int) 

Draws a closed polygon defined by arrays of x and y coordinates. 

• drawFolyqnn (Polygon) 

Draws the outline of a polygon defined by the specified Polygon object. 

• drawPpiylinstintn, int[] t int) n 1 

• „ „ Draws a sequence of connected lines defined by arrays of x and y coordinates 

• drawRect (int int, int, int) 

Draws the outline of the specified rectangle. 

• drawRQUPdRect <int int, int. int, int, int} 

Draws an outlined round-cornered rectangle using this graphics contexts current color. 
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• drawStfing (String, int, int) 

Draws the text given by the specified string, using this graphics context's current font ajid 
color. 

• filKDrect (int, int Int, int. boolean) 

Paints a 3-D highlighted rectangle filled with the current color. 

• fillArc (int, int, int, int, int, int) 

Fills a circular or elliptical arc covering the specified rectangle. 

• filKJyalOntiht.irrf.irrt) 

Fills an oval bounded by the specified rectangle with the current color. 

• fiiEoJygoiiMLintllJnt) 

Fills a closed polygon defined by arrays of x and y coordinates. 

• fillPoivoon (Polygon) 

Fills the polygon defined by the specified Polygon object with the graphics context's cujient 
color. 

• fiilBfiCtOnt, int, int, int) 

Fills the specified rectangle. 

• filtRoundRect (int, int, int, Int, int, int) 

Fills the specified rounded corner rectangle with the current color. 

• finalize ( \ 

Disposes of this graphics context once It is no longer referenced. 

• geiClip.0 

Gets the current clipping area. 

• aetClipBounds ( ) 

Returns the bounding rectangle of the current clipping area. 

• q etClipRe ctQ 

Deprecated. 

• ggtCobrO 

Gets this graphics context's current color. 

• getFont f) 

Gets the current font, 

Gets the font metrics of the current font 

• getFontMetrics (Font) 

Gets the font metrics for the specified font 

• s etClip (int, int, int, int) 

Sets the current clip to the rectangle specified by the given coordinates. 

• sei&ia (Shape) 

Sets the current clipping area to an arbitrary dip shape. 

• setCotor (Color) 

Sets this graphics context's current 

• setFflnj (Font) 

Sets this graphics context's font to the specified font. 

• setPaintMode Q 

Sets the paint mode of this graphics context to overwrite the destination with this graphics 
context's current color, 

• MftORMQft (Color) 

Sets the paint mode of this graphics context to alternate between this graphics context 1 
current color and the new specified color. 

• toString ( ) 

Returns a String object representing this Graphics object's value. 

• translate (int, int) 

Translates the origin of the graphics context to the point (x, y) in the current coordinate system. 
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i7oa ^ < ! ELEMENT drawLine EMPTY> 

r < \ ATTLIST drawLine x1 CDATA #REQUIRED 
X2CDATA #REQL»RED 
1226 ^ y1 CDATA #REQUIRED 

y2 CDATA #REQUIRED 



< ! ELEMENT clearRect EMPTY> 

< I ATTLIST clearRect x CDATA #REQUIRED 

y CDATA #REQUIRED 
width CDATA # REQUIRED 
height CDATA #REQUIRED 

> 
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drawLine (23, 43 t 60, 60); 
drawLine (50, 60, 27, 80); 
clearRect (0,0, 10, 10); 



1704 



i 



«208 J 
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<?xrnlversion="1.0 tt ?> 

< ! DOCTYPE jgml SYSTEM ■■jgml.dtcT > 

<jgml> 

15-00 < 1902 - <drawUnex1="23"y1= ,, 43"x2="50y2="60"/> 
1904 - < drawLine x1 ="50" y1 = rt 60" x2= M 27 y2="80" / > 
1906 - < ctearRect x^O" y='*0" width="1 0" height= r i 0" / > 
< figmf > 
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DECLARATION AND POWER OF ATTORNEY FOR 
PATENT APPLICATION 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below 
next to my name; 

I believe I am the original, first and sole inventor (if only one name 
is listed below) or an original, first and joint inventor (if plural names are 
listed below) of the subject matter which is claimed and for which a patent is 
sought on the invention entitled 

METHOD AND APPARATUS FOR CONVERTING PROGRAMS AND SOURCE CODE FILES WRITTEN IN 
A PROGRAMMING LANGUAGE TO EQUIVALENT MARKUP LANGUAGE FILES 

the specification of which (check one) 

X is attached hereto. 

was filed on 

as Application Serial No. 

and was amended on 

(if applicable) 

I hereby state that I have reviewed and understand the contents of the above 
identified specification, including the claims, as amended by any amendment 
referred to above. 

I acknowledge the duty to disclose information which is material to the 
patentability of this application in accordance with Title 37, Code of Federal 
Regulations, §1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, 
§119 of any foreign application (s) for patent or inventor's certificate listed 
below and have also identified below any foreign application for patent or 
inventor 1 s certificate having a filing date before that of the application on 
which priority is claimed: 

Prior Foreign Application (s) : Priority Claimed 

Yes No 

(Number) (Country) (Day /Month/ Year) 



I hereby claim the benefit under Title 35, United States Code, §120 of any 
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United States application (s) listed below and, insofar as the subject matter 
of each of the claims of this application is not disclosed in the prior United 
States application in the manner provided by the first paragraph of Title 35, 
United States Code, §112, I acknowledge the duty to disclose information 
material to the patentability of this application as defined in Title 37, Code 
of Federal Regulations, §1.56 which occurred between the filing date of the 
prior application and the national or PCT international filing date of this 
application: 



(Application Serial #) (Filing Date) (Status) 

I hereby declare that all statements made herein of my own knowledge are true 
and that all statements made on information and belief are believed to be 
true; and further that these statements were made with the knowledge that 
willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the 
application or any patent issued thereon. 

POWER OF ATTORNEY: As a named inventor, I hereby appoint the following 
attorneys and/or agents to prosecute this application and transact all 
business in the Patent and Trademark Office connected therewith. 

John W. Henderson, Jr., Reg. No. 26,907; Thomas E. Tyson, Reg. No. 28,543; 
James H. Barksdale, Jr., Reg. No. 24,091; Casimer K. Salys, Reg. No. 28,900; 
Robert M. Carwell, Reg. No. 28,499; Douglas H. Lefeve, Reg. No. 26,193; 
Jeffrey S. LaBaw, Reg. No. 31,633; David A. Mims, Jr., Reg. 32,708; Volel 
Emile, Reg. No. 39,969; Anthony V. England, Reg. No. 35,129; Leslie A. Van 
Leeuwen, Reg. No. 42,196; Christopher A. Hughes, Reg. No. 26,914; Edward A. 
Pennington, Reg. No. 32,588; John E. Hoel, Reg. No. 26,279; Joseph C. Redmond, 
Jr., Reg. No. 18,753; Marilyn S. Dawkins, Reg. No. 31,140; Duke W. Yee, Reg. 
No. 34,285; Mark E. McBurney, Reg. No. 33,114; and Colin P. Cahoon, Reg. No. 
38,836; Joseph R. Burwell, Reg. No. P-44,468; Rudolph J. Buchel, Reg. No. 
P-43,448; Stephen R. Loe, Reg. No. 43-757. 

Send correspondence to: Duke W. Yee, Carstens, Yee & Cahoon, LLP, P.O. Box 
802334, Dallas, Texas 75380 and direct all telephone calls to Duke W. Yee, 
(972) 362-2001 

FULL NAME OF SOLE OR FIRST INVENTOR: Michael Richard Cooper 



RESIDENCE : 12804 Medina River Way 
Austin, Texas 78732 



INVENTORS SIGNATURE: 




DATE : s/srM^ 
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FULL NAME OF SECOND INVENTOR: Rabindranath Dutta 

INVENTORS SIGNATURE: JLj?U^< ^^u^-^-^C ^^^i DATE: S~/ fy/ 1 ^^ 7 



RESIDENCE : 3401 Parmer Lane W. , #835 
Austin, Texas 78727 

CITIZENSHIP: India 

POST OFFICE ADDRESS: SAME AS ABOVE 



UK : Kelvin KoaeryK .Lawrence , 
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FULL NAME OF THIRD INVENTOR: Kelvin Roderick Lawrence 

INVENTORS SIGNATURE: 
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